昨天提到，開始使用 AI 寫 Code 之後，我反而更想知道：

為什麼這段 Code 要這樣寫？

既然 AI 可以幫忙讀 Code，那除了叫它寫功能之外，是不是也可以拿來幫我更快理解一個 Android 專案？
所以今天決定先從自己的 Android Project 開始測試。
這個 Project 是以前寫的，我自己對裡面的架構和功能已經有一定程度的了解，剛好可以拿來確認 AI 到底有沒有理解正確。

第一次：先請 AI 告訴我這是什麼 Project

一開始我問得很單純：

先不要修改任何程式碼，閱讀這個 Android Project，告訴我目前的架構與主要開發方式。

包含主要 Feature、Navigation、UI、State / Event、ViewModel / Data Layer、Flow / Coroutine，以及 Architecture。

每個判斷盡量提供 Code Evidence，不確定的地方不要猜。

AI 很快整理出這個 Project 使用：

• Single Activity + Fragment
• XML View System
• Navigation Component + Safe Args
• MVVM
• LiveData 為主，部分搭配 Flow
• Coroutine
• Repository
• Room
• Retrofit
• 手動建立 Repository / ViewModel Factory

甚至還有找到一些更細的東西，例如 Navigation 其實有外層與 Home 內層兩個 NavHost、部分頁面使用 Shared ViewModel 傳遞狀態等等。

因為這是自己的 Project，所以我大概知道它講的是不是對的。
結果其實沒有什麼大問題。
但看完之後，我有一種很奇怪的感覺：

好像知道了很多，但又好像沒有真的更懂這個 Project。

知道用了什麼，不代表知道它怎麼運作

第一份回答比較像是 Project 的技術盤點。
它可以告訴我：

XML
Fragment
MVVM
LiveData
Flow
Coroutine
Repository
Room

但如果今天我真的是第一次接觸這個 Project，我看完可能只會知道：
「喔，原來這個專案用了這些東西。」

可是如果接著問我：

• 一個畫面的資料到底從哪裡來？
• 使用者操作之後，State 怎麼改變？
• 為什麼資料改變後 UI 會更新？
• 哪個 State 是 Fragment 自己的？
• 哪個 State 是 ViewModel 的？
• Repository 到底在這個 Feature 裡扮演什麼角色？

我可能還是答不太出來。

所以我開始覺得：

Project Overview 其實比較像索引，不是真的理解。

第二次：那直接丟一個 Requirement 呢？

接著我換了一個方式。

假設今天收到需求：

「在 Focus Feature 裡新增正計時功能。」

這次我不要 AI 寫 Code，只請它先調查：

1. 從哪裡開始找？
2. 現在的 Data Flow 是什麼？
3. 哪些檔案確定受影響？
4. 哪些只是可能受影響？
5. Requirement 還有哪些地方不清楚？
6. Coding 前還需要知道什麼？

這次的結果比第一次有意思很多。

AI 發現這個 Project 其實已經存在一部分正計時功能。
包含 StopWatchFragment、STOPWATCH mode、Foreground Service、FocusSession 等等。
甚至還發現目前 StopWatch 儲存紀錄時，有一個 isPomodoro 的值看起來可能跟資料語意不一致。
這些都是我覺得滿有價值的發現。

代表 AI 並不是只看檔名猜答案，它真的有沿著 Code 往下找。
可是另一個問題又出現了。
資訊太多了。

它一次給了我大量的：

• 調查方向
• Data Flow
• Confirmed files
• Possible files
• Requirement questions
• Edge Cases
• Coding 前要確認的事情

每一段單獨看都合理。
但全部一起出現時，我反而要自己再整理一次：

所以這個功能「現在到底是什麼狀態」？

第三次：那就叫 AI 完整 Trace 一個 Feature

我開始懷疑是不是前面問得還不夠具體。

所以第三次直接挑了一個我熟悉的 Day Feature，請 AI 從「使用者進入 Day 畫面」開始完整 Trace。

這次我問得非常細：

• DayFragment 怎麼被建立？
• ViewModel 怎麼取得？
• Dependencies 在哪裡建立？
• UI observe 哪些 State？
• State 最原始的資料在哪？
• Flow / LiveData 中間怎麼轉？
• 切換日期後資料怎麼一路回到 UI？
• State 分別由誰管理？

這次 AI 確實回答得非常詳細。

它甚至可以整理出類似這樣的 Flow：

User 點擊日期
        ↓
DayFragment
        ↓
dayVM.selectDate(date)
        ↓
_selectedDate
        ↓
switchMap
        ↓
Repository
        ↓
Room DAO
        ↓
Flow
        ↓
combine()
        ↓
DayUiState
        ↓
LiveData
        ↓
DayFragment
        ↓
更新 UI

它也找出了不同 State 的 Owner、Shared ViewModel 的 Scope、Repository 的建立方式，以及日期改變後各條 Flow 怎麼重新取得資料。

這次已經不能說 AI「講得太淺」了。
但我又遇到另一個問題。

太詳細了，我反而記不住。

原來「詳細」跟「理解」不是同一件事

這也是今天做到第三次之後，我覺得最有意思的地方。
一開始我以為：

AI 解釋得不夠清楚
        ↓
那就叫它詳細一點
        ↓
我應該就會更懂

但實際上卻變成：

太概括
→ 知道用了什麼，但不知道怎麼運作

非常詳細
→ 每一段都看得懂，但看完抓不到重點

這好像也是我以前叫 AI 解釋 Code 時很常遇到的問題。

我會叫它：

「幫我詳細解釋這段 Code。」

然後得到一篇超級完整的回答。
看的當下每一句好像都懂。
關掉之後，卻不一定能自己重新解釋一次。

這時候我才發現，我真正需要的可能不是：

Explain everything.

而是：

先幫我建立 Mental Model，再讓我決定哪裡需要深入。

如果重新來一次，我希望 AI 先只告訴我這些

以剛才的 Day Feature 為例，第一輪其實不用告訴我所有 State、所有 DAO、所有轉換。

我可能只需要先理解：

PlanFragment
    ↓
DayFragment
    ↓
DayViewModel
    ↓
Repository
    ↓
Room DAO
    ↓
Flow
    ↓
DayUiState
    ↓
DayFragment

接著知道：

Day 畫面的核心 State 是日期。

日期改變後，ViewModel 會根據新的日期取得 Todo、Goal、Event、Holiday 等資料，再組成 DayUiState 回到畫面。

到這裡，我腦中其實就已經有第一張地圖了。

接下來如果我想知道：

「為什麼日期一改，資料就會重新查？」

再深入 switchMap、Flow、combine()。

如果想知道：

「為什麼不同 Tab 可以知道同一天？」

再去看 Shared ViewModel。

而不是第一輪就全部一起塞進來。

我還是想看 Code，但看的方式可以不一樣

另外一個我今天注意到的事情是：

即使 AI 已經解釋得很完整，我還是會想打開實際 Code 看。

以前可能會覺得：

都已經叫 AI 解釋了，為什麼最後還是要自己看 Code？

但現在反而覺得這件事沒有問題。

AI 不需要取代我讀 Source Code。

它比較適合先告訴我：

這個 Feature 的地圖長什麼樣子，以及最值得先看的 Code 在哪裡。

例如 Day Feature，我可能先只看：

PlanPagerAdapter.createFragment()
→ DayFragment 從哪裡出現

DayFragment.observeViewModel()
→ UI 在觀察什麼

DayViewModel.selectDate()
→ 日期怎麼改變

DayViewModel.dayContentState
→ 資料怎麼組成畫面 State

這樣 AI 幫我做的不是「把所有 Code 翻譯成中文」。
而是讓我不用從幾十個檔案開始找。

所以我想試試看另一種方式

今天的三次嘗試讓我開始整理出一個新的理解流程：

先建立 Overview
        ↓
建立 Mental Model
        ↓
只看一條 Main Flow
        ↓
找出幾個重要 Code Anchor
        ↓
自己看真正的 Code
        ↓
再深入其中一個 Why
        ↓
最後自己重新解釋一次

而且最後一步可能很重要。

如果 AI 講完之後，我只是覺得：

「嗯，我看懂了。」

那可能還不是真的懂。

之後我想試著反過來：

換我解釋給 AI 聽。

讓 AI 不要重新教我一次，只檢查我的理解哪裡有錯、哪一段漏掉。

如果我可以不用看答案，自己說出：

使用者切換日期後，是先改變 ViewModel 裡的日期 State，接著依賴日期的資料流重新取得 Room 資料，再 combine 成新的 UiState，最後讓 Fragment 更新畫面。

那可能才比較接近真的有吸收。

Day 2：AI 不只是要回答正確，還要讓我理解

今天原本只是想測：

AI 到底看不看得懂我的 Android Project？
結果 AI 其實看得比我預期好。
反而是我發現自己問錯了一個問題。

我不只是想知道：

AI 能不能找到正確答案？

我真正想要的是：

AI 能不能幫我更快建立對 Code 的理解，而且最後這份理解是真的留在我腦中的？

所以今天先替自己的 Workflow 留下一條規則：

不要用回答的資訊量判斷自己有沒有學會。

接下來我想把「請 AI 詳細解釋」慢慢改成：

Mental Model → Main Flow → Code Anchor → Why → Teach Back

AI 可以幫我讀得更快。

但最後能不能不看答案，自己說出這段 Code 為什麼這樣運作，可能才是我要的「真的懂」。

明天，我想開始把「理解」換成另一個更實際的測試：

如果我只給 AI 一句需求，不告訴它應該怎麼分析，它會直接開始寫 Code，還是會先搞懂自己到底要改什麼？

下一集見:)